Call features for automatic call distribution system

ABSTRACT

Call features for an Automatic Call Distribution (ACD) system implemented within a packet-based telephone environment are disclosed. Within a packet-based network, data messages are transferred between the ACD system and customer telephone stations while the customer waits for an attendant to become available. These data messages allow the customer to be informed of his/her current status within the priority order and further allows the customer to initiate a number of customer oriented operations. These operations include selecting music to listen to while waiting, requesting to be alerted when an attendant becomes available, and initiating a browser session for accessing data information. Overall, the status reports in combination with the initiating of one or more of the customer oriented operations can make the time spent waiting for an attendant a more productive and pleasant experience for the customer.

FIELD OF THE INVENTION

This invention relates generally to automatic call distribution systemsand, in particular, to apparatus and methods used to implement callfeatures for automatic call distribution systems.

BACKGROUND OF THE INVENTION

The use of Automatic Call Distribution (ACD) systems has become astandard practise among corporations that rely upon telephone networksto interface with customers. The primary operation of ACD systems is toanswer customer calls and distribute such calls to attendants as theattendants become available. Such ACD systems are currently being usedto control customer support lines, fast food delivery operations,airline/train reservation services and 1-800 telephone number salesoperations, to name only a few implementations.

FIG. 1 is a high level block diagram illustrating a standard telephonynetwork 20 coupled to a well-known ACD controller 22 and a plurality ofremote telephone stations 24. As depicted, the ACD controller 22 isfurther coupled to a memory storage device 26 and a plurality ofattendant telephone stations 28. The ACD controller 22, the memorystorage device 26 and the attendant telephone stations 28 together canbe referred to as an ACD system, the components of the ACD systemtypically being located together at an ACD center 30.

In well-known implementations, the ACD controller 22 is built upon aPrivate Branch Exchange (PBX) device with specialized softwareimplemented to create the ACD functionality. This PBX device may be ananalog device, but is more commonly a digital PBX device such as aMeridian Ml PBX produced by Nortel Networks Corporation of Brampton,Ontario, Canada. The ACD controller 22 is coupled to the telephonynetwork 20 via a number of analog telephone lines, or optionally in adigital fashion via high speed interconnections such as T1 telephonelines.

The attendant telephone stations 28 comprise telephone handsets orheadsets to communicate with customers at the remote telephone stations24. Further, the attendants typically also have computer terminals (notshown) in order to take orders and/or information from the customers.The remote telephone stations 24, on the other hand, can be standardanalog telephones coupled to the telephony network 20 directly, digitaltelephones coupled to the telephony network 20 via their own PBX system,or even wireless telephones coupled to wireless telephony networks.

In normal operation, the well-known ACD controller 22 answers callrequests from customers at the remote telephone stations 24, determinesif an attendant is available to answer the call from the customer,connects the call to the attendant if one is available and, if anattendant is not currently available, informs the customer of this fact.Informing the customer that no attendant is currently available to takethe call can be done in a number of ways but commonly includes playing arecorded voice message followed by the playing of music. After informingthe customer that no attendant is currently available, the ACDcontroller 22 next puts the answered calls in a priority order basedupon the order they were answered and forwards each call to an attendantas the attendants become available.

One key advantage for a corporation using the ACD controller 22 is theflexibility that such a system provides. A corporation can schedule aset number of attendants to work during a set period of time withouthaving to worry about the demand for their attendants exceeding thenumber working. The ACD controller 22 can compensate for access demandfor the attendants during a particular period by answering the callsfrom the customers and essentially putting the call on hold until anattendant is available.

The key problem with the ACD controllers as currently designed is thewaiting time that they cause on the part of the customers calling intothe ACD systems. In some circumstances, a remote telephone station 24could remain in an active telephone session with the ACD controller 22for a long period of time before the ACD controller 22 forwards the callto one of the attendant telephone stations 28. This can result indissatisfaction on the part of the customer as the customer must stay onthe line to maintain his/her place within the priority order,essentially forcing the user to keep his/her ear glued to the telephonehandset to wait for the attendant. Using handsfree operation can help,but the user must still remain within a close proximity to the remotetelephone station 24. Further, this results in the customer's telephoneline being left in an active state during which time the customer isprevented from receiving and initiating telephone sessions.

To productively utilize this waiting time, many well-known ACDcontrollers offer customers a number of options to select from prior tothe call being forwarded to an attendant. In these implementations, theACD controller 22 plays a recorded voice message to the customer, therecorded voice message providing the options to be selected from and thetelephone keys that the customer must press to select each option. Forexample, this recorded voice message could specify that the pressing ofdigit “1” indicates “English service” while the pressing of digit “2”indicates “French service”. Further, in another example in which theattendants organize travel arrangements, the recorded voice messagecould specify that the pressing of certain telephone keys indicates thecustomer's desire to travel to specific destination cities.

After receiving the recorded voice message from the ACD controller 22,the customer can subsequently select one of the options by pressing thecorresponding telephone keys; the pressing of the telephone keysresulting in Dual Tone Multi-Frequency (DTMF) signals being sent to theACD controller 22 from the customer's remote telephone station 24. TheACD controller 22 receives these DTMF signals and proceeds to processthe call taking into consideration the customers selections. Thisprocessing of the call could include sending additional recorded voicemessages to the customer that provide additional options to select from,sending additional recorded voice messages to the customer that provideinformation corresponding to the customer's previous selection and/orsending the options selected by the customer to the attendant the callis eventually directed to. Overall, this type of interactivecommunication system is generally referred to as an Integrated VoiceResponse (IVR) system.

Despite the improvements made with the use of IVR, traditional ACDsystems still require a customer to maintain a telephone connection withthe ACD controller and wait for service from an attendant. Further,typical IVR systems only allow for a limited amount of information to beprovided to the customer, this information being restricted to data thathas previously been audibly recorded and has been set-up to be selectedvia the telephone keys. Other information outside the scope of theaudibly recorded data cannot be provided. Yet further, the user of theseIVR systems can often get confused with too many voice prompt optionsand/or end up going around in circles through menus while trying tolocate a particular piece of information. Even further, these IVRsystems can be slow for the user to navigate and get the desiredinformation.

SUMMARY OF THE INVENTION

Preferred embodiments of the present invention are directed to callfeatures for an Automatic Call Distribution (ACD) system implementedwithin a packet-based telephone environment. Within these preferredembodiments, data messages are transferred between the ACD system andcustomer telephone stations while the customer waits for an attendant tobecome available. These data messages allow the customer to be informedof his/her current status within the priority order and further allowthe customer to initiate a number of customer oriented operations. Theseoperations preferably include selecting music to listen to whilewaiting, requesting to be alerted when an attendant becomes available,and initiating a browser session for accessing data information.Overall, the status reports in combination with the initiating of one ormore of the customer oriented operations can make the time spent waitingfor an attendant a more productive and pleasant experience for thecustomer.

The present invention, according to a first broad aspect, is anAutomatic Call Distribution (ACD) controller arranged to be coupledthrough a packet-based network to a plurality of remote telephonestations and one or more attendant telephone stations. The ACDcontroller includes call reception logic that controls the establishmentof telephone sessions between the remote telephone stations and theattendant telephone stations. First, the call reception logic receivescall initiation signals from a particular one of the remote telephonestations and subsequently monitors if an attendant availabilityparameter is met. If the attendant availability parameter is not met,the call reception logic proceeds to send a data information message tothe particular remote telephone station via the packet-based network. Onthe other hand, if the attendant availability parameter is met, the callreception logic proceeds to establish an audio channel between theparticular remote telephone station and a particular one of theattendant telephone stations.

In preferred embodiments, the call reception logic further queries thecapabilities of the particular remote telephone station prior to sendingthe data information message; the capabilities determining the formatfor the data information message. Yet further, the call reception logicpreferably determines a waiting parameter to be presented to a user atthe particular remote telephone station, the data information messageincluding this waiting parameter. In some embodiments, the waitingparameter is a priority order number and/or an estimation of the timebefore the attendant availability parameter will be met. In even furtherpreferred embodiments, the data information message includes an alertrequest option, a plurality of audio options, and/or a browser requestoption. These options allow for the user at the remote telephone stationto initiate a variety of operations to be performed while waiting forthe attendant availability parameter to be met.

The present invention, according to a second broad aspect, is an ACDcontroller similar to the ACD controller of the first broad aspect, butwith a modified call reception logic. In this aspect, the call receptionlogic receives call initiation signals from a particular one of theremote telephone stations and subsequently initiates a browser sessionwith the particular remote telephone station such that the particularremote telephone station can access data information within a browserformat. Next, the call reception logic monitors for receipt of anattendant request message being sent from the particular remotetelephone station. If an attendant request message is received, the callreception logic monitors if an attendant availability parameter is met.If the attendant availability parameter is met, the call reception logicestablishes an audio channel between the particular remote telephonestation and a particular one of the attendant telephone stations.

The present invention, according to a third broad aspect, is a switchingdevice arranged to be coupled through a telephone network to a remotetelephone station and an ACD system that includes an attendant telephonestation. In this aspect, the switching device includes alert requestlogic that is operable when the remote telephone station is connected tothe ACD system through the switching device. The alert request logicoperates to monitor for receipt of an alert request activation signal.If the alert request activation signal is received, the alert requestlogic stores a directory number corresponding to the remote telephonestation, disconnects the remote telephone station from the switchingdevice and monitor for an attendant ready signal from the ACD system. Ifthe attendant ready signal is received, the alert request logic proceedsto initiate a telephone session with the remote telephone station usingthe stored directory number in order to connect the remote telephonestation and the ACD system.

The present invention, according to a fourth broad aspect, is atelephone station arranged to be coupled through a telephone network toan Automatic Call Distribution (ACD) system comprising at least oneattendant telephone station. The telephone station includes alertrequest logic that is operable when the telephone station is connectedto the ACD system. In this aspect, the alert request logic monitors forreceipt of an alert request activation signal. If the alert requestactivation signal is received, the alert request logic periodicallysends a recorded voice message to the ACD system indicating how to sendan attendant ready signal to the alert request logic, monitors for anattendant ready signal from the ACD system and, if the attendant readysignal is received, initiates a alert operation on the telephonestation.

The present invention, according to another aspect, is an ACD systemcomprising an ACD controller according to the first broad aspect and anumber of attendant telephone stations coupled to the ACD controller. Inanother aspect, the present invention is a telephone network comprisingthe ACD system of above, a packet-based network and one or more remotetelephone stations. The present invention, according to even furtheraspects, is a method performed within an ACD controller of the firstbroad aspect and a method performed within a switching device of thethird broad aspect.

Other aspects and features of the present invention will become apparentto those ordinarily skilled in the art upon review of the followingdescription of specific embodiments of the invention in conjunction withthe accompanying figures.

BRIEF DESCRIPTION OF THE DRAWINGS

The preferred embodiment of the present invention is described withreference to the following figures, in which:

FIG. 1 is a high level block diagram of a standard telephony networkcoupled to an ACD system;

FIG. 2 is a high level block diagram of a packet-based network coupledto an ACD system according to a first preferred embodiment of thepresent invention;

FIG. 3 is a high level block diagram of a packet-based network coupledto an ACD system according to a second preferred embodiment of thepresent invention;

FIG. 4 is a block diagram of an ACD controller according to a preferredembodiment of the present invention;

FIG. 5 is a software layers model illustrating the various protocollayers according to preferred embodiments of the present invention;

FIG. 6 is a flow chart illustrating the steps performed by the ACDcontroller within the ACD system of FIG. 2 during a call receptionoperation;

FIG. 7 is a flow chart illustrating the steps performed by the ACDcontroller within the ACD system of FIG. 2 during a music choice softkeyoperation;

FIG. 8 is a flow chart illustrating the steps performed by the ACDcontroller within the ACD system of FIG. 2 during an alert requestsoftkey operation;

FIG. 9 is a flow chart illustrating the steps performed by the ACDcontroller within the ACD system of FIG. 2 during a browser requestsoftkey operation; and

FIG. 10 is a flow chart illustrating the steps performed by a switchdevice according to an embodiment of the present invention during analert request operation.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Preferred embodiments of the present invention are directed to ACDsystems implemented within a packet-based environment. In thesepreferred embodiments, customers using packet-based telephone stationscan send/receive both voice and data communications to/from the ACDsystem via a packet-based network which is preferably an InternetProtocol (IP) network. The combination of voice and data communicationsallows for additional ACD call features, as will be described hereinbelow, to be implemented in the packet-based environment that would bedifficult or impossible to be implemented in the traditional analogtelephony environment.

FIG. 2 is a high level block diagram illustrating a packet-basednetwork, in this case an IP network 40, coupled to an ACD systemaccording to a first preferred embodiment of the present invention. Asdepicted, the IP network 40 is coupled to an ACD controller 42, aplurality of attendant telephone stations 44, a plurality of attendantconsole devices 46, and a variety of remote telephone stations 48 aswill be described herein below. The components 42,44,46,48 coupled tothe IP network 40 communicate with each other by sending data and/orvoice within IP packets traversing the IP network 40, each of thesecomponents being addressed by a unique 32 bit IP address. The ACDcontroller 42, the attendant telephone stations 44 and the attendantconsole devices 46 can together be considered to comprise an ACD systemin this situation.

Preferably, the IP network 40 is a managed IP network with sufficientquality of service (QoS) to provide real time voice services. Forinstance, IP networks within many enterprises currently have thenecessary QoS for such voice services. Unfortunately, the publicInternet presently does not provide satisfactory QoS for real time voicecommunications, though with lower quality standards such a network couldstill be utilized. The main impairments to real time voicecommunications are latency and packet loss, both of which are currentlyrelatively high on the public Internet. As these problems are reduced inthe future, it should be understood that the preferred embodiments ofthe present invention could be implemented within such a public Internetnetwork. Hence, the preferred embodiments of the present inventionshould not be limited to a managed IP network.

The components of the ACD system, those being the ACD controller 42, theattendant telephone stations 44 and the attendant console devices 46,preferably are located at a central ACD center 50. Since, in thedepicted situation, these components communicate through the IP network40 which could span a large geographical area, alternative embodimentsdo not have the ACD controller 42, the attendant telephones 44 and theattendant console devices 46 located at a central location. In thesealternative embodiments, the components could be divided into two ormore sets of components, each set being located at a different location.

Whether the components are located at a central location or not, eachattendant within the ACD system preferably has both an attendanttelephone station 44 and an attendant console device 46, both devicesbeing coupled to the IP network 40 by a physical interface connectionsuch as an ethernet interface (not shown). The attendant telephonestations 44 are preferably one of an IP enabled telephone station, an IPenabled device with a headset, and an IP enabled telephone station withan analog headset attachment. The attendant console devices 46 arepreferably a computing device, such as a personal computer, withspecialized software or alternatively are dedicated hardware devices. Itis further noted that an attendant telephone station 44 and an attendantconsole device 46 could, in some cases, be implemented together as avoice enabled personal computer running a soft client program, thispersonal computer having a microphone and speakers for this purpose.

Similar to the attendant telephone stations 44, the remote telephonestations 48 can take a number of forms. In the example illustrated inFIG. 2, the remote telephone stations 48 include an IP enabled telephonestation coupled to the IP network through a high speed Digital ServiceLoop (DSL) line; a wireless IP enabled telephone station thatcommunicates with a basestation 52 coupled to the IP network 40; acomputing device, such as a personal computer with speakers andmicrophone, running an IP soft phone voice application program, thecomputing device coupled to the IP network 40 preferably via an ethernetinterface (not shown); and a plurality of IP enabled telephone stationsindependently coupled to a Local Area Network (LAN) that is furthercoupled to the IP network 40. It should be understood that a remotetelephone station utilized by a user to communicate with the ACD systemaccording to preferred embodiments of the present invention should notbe limited to the above described devices but could be any IP enableddevice capable of voice and data communications.

The ACD controller 42 is preferably a workstation or personal computerwith a Digital Signal Processing (DSP) card included. The ACD controller42, according to these preferred embodiments of the present invention,will be described herein below with reference to FIG. 4 for thecontroller comprising a high performance personal computer with a DSPcard. In alternative embodiments, the ACD controller 42 is a dedicatedhardware device with specialized circuitry. In yet further alternatives,the ACD controller 42 could be a high end personal computer orworkstation without a DSP card, the DSP algorithms being run on the mainprocessor of the personal computer in this case. It is noted that thislast alternative could reduce the number of calls the ACD controller 42could handle when compared to the preferred case in which a DSP isincluded.

In operation, the ACD controller 42 acts as a control mechanism for theACD system. IP voice calls initiated by a user at one of the remotetelephone stations 48 are initially directed to and are subsequentlycontrolled by the ACD controller 42. The initiation of an IP voice callin preferred embodiments is done by establishing a signaling channelbetween the remote telephone station 48 and the ACD controller 42 withuse of one of several Voice over IP (VoIP) protocols. The descriptionherein below will be with respect to the H.323 VoIP protocol defined bythe International Telecommunications Union (ITU), although it should berecognized that other VoIP protocols are equally applicable. It shouldbe noted that a VoIP telephone session between the ACD controller 42 andone of the remote telephone stations 48 requires the adherence to manydifferent well-known protocols. The description of these protocols forpreferred embodiments of the present invention will be described belowwith reference to FIG. 5.

FIG. 3 is a high level block diagram similar to FIG. 2 but with the IPnetwork 40 coupled to an ACD system according to a second preferredembodiment of the present invention. In this figure, all of thecomponents are the same as those depicted in FIG. 2, but with adifferent configuration within the ACD center 50. In this case, an ACDLAN 56 is used to interconnect the ACD controller 42, the attendanttelephone stations 44 and the attendant console devices 46. The LAN 56is further coupled to the IP network 40 through a router or a firewalldevice (not shown). It should be understood that further embodimentsthat allow for communication between the ACD controller 42 and theremote telephone stations 48 are further possible while still beingwithin the scope of the present invention.

FIG. 4 is a block diagram of the ACD controller 42 according to apreferred embodiment of the present invention. In this preferredembodiment, the ACD controller 42 is a modified high performancepersonal computer comprising an RJ45 jack 80 coupled to the IP network40; an Ethernet card 82 coupled to the RJ45 jack 80; a high speed bus 84coupled to the Ethernet card 82; and a DSP card 86, a hard disk drive 88and a workstation motherboard 90 each coupled to the high speed bus 84.The motherboard 90, as depicted in FIG. 4, comprises a processor 92, aRandom Access Memory (RAM) device 94 and a Direct Memory Access (DMA)controller 96. Further, the ACD controller 42 comprises an AC jack 98coupled to a power supply 100 that powers the personal computer.

Within the ACD controller 42 of FIG. 4, the processor 92 in combinationwith the RAM 94 and the DMA controller 96 control and process alloperations for the ACD controller 42 that do not require significantsignal processing power. These operations include the processing ofnumerous packet software layers as will be described below withreference to FIG. 5, the running of software that performs callreception operations as will be described below with reference to FIG.6, the storing and retrieving of data from the hard disk 88, the runningof HyperText Transfer Protocol (HTTP) browser sessions with the remotetelephone stations 48 as will be described below with reference to FIG.9, and other normal functions for a personal computer to perform. TheDSP card 86, on the other hand, performs operations that require largesignal processing power such as voice coding and digital filtering ofDTMF tones.

The software layers used to encapsulate data being sent between the ACDcontroller 42 and the remote telephone stations 48 are now describedwith reference to FIG. 5, along with a description concerning thecomponents within the ACD controller 42 that preferably process thesesoftware layers. FIG. 5 illustrates an International StandardsOrganization (ISO) 7 level model of these software layers that has beenmodified for the implementation of preferred embodiments of the presentinvention.

As depicted in FIG. 5, the lowest layer, Layer 1 (L1), is preferably anEthernet connection physical layer. Within FIG. 4, the Ethernet card 82operates as an interface with this physical layer by stripping off theEthernet header from incoming packets and adding an Ethernet header topackets being output from the ACD controller 42. The Ethernet card 82acts under the control of the processor 92, this control beingdetermined by the Ethernet hardware drivers which form the Data LinkLayer 2 (L2) within FIG. 5.

It should be understood that the use of an Ethernet physical layer as aninterface with the IP network 40 should not limit the scope of thepresent invention. For instance, other interfaces are possible with theIP network 40 such as Asynchronous Transfer Mode (ATM) interfaces, TokenRing Local Area Network (LAN) interfaces, Frame Relay interfaces,Digital Subscriber Line (DSL) interfaces, or other physical layerinterfaces that can use the IP Layer 3 protocols. If different physicalconnections are used than Ethernet, Layers 1 and 2 of FIG. 5 would becorrespondingly different and the Ethernet card 82 would be replacedwith a different interface device within FIG. 4. The layers above thesecond layer are not affected by what the physical connection utilizedis.

In the preferable model of FIG. 5, Layer 3 (L3) is the IP network layer,this network layer being standard to all IP networks. Further depictedwithin FIG. 5, Layer 4 (L4) consists of two transport layer services,those being User Datagram Protocol (UDP) and Transmission ControlProtocol (TCP). A UDP layer provides a fast but non-guaranteed datadelivery service based on a “best effort” to deliver packets. A TCPlayer provides a slower but guaranteed delivery of packets, usingretransmission for any lost or erroneous packets. Within the ACDcontroller 42 of FIG. 4, the processor 92 in combination with the RAM 94and the DMA controller 96 interface with these network and transportlayers. For the case of an incoming operation, the data packets outputfrom the Ethernet card 82 are placed into the RAM 94 by the DMAcontroller 96 which is controlled by the processor 92. Subsequently, theprocessor 92 reads out the data packets from the RAM 94, processes themfor the IP header of Layer 3, separates the packets between the UDP andTCP transport layer services of Layer 4 (L4) and processes the receiveddata packets for their applicable one of these services. For the case ofan outputting operation, the processor 92 attaches headers consistentwith the Layer 3 and 4 services to data packets prior to forwarding themto the RAM 94. Next, the DMA controller 96 sends the data packets storedin the RAM 94 to the Ethernet card 86 for physical layer processing asdescribed above.

Above Layer 4 (L4) are the higher level protocols of Layers 5, 6 and 7(L5, L6, L7) which, in the case depicted in FIG. 5, provide an audiochannel, VoIP call signaling and call control channels, a remote screenand softkey control channel according to preferred embodiments of thepresent invention, and a web server channel. Each of these higher levelprotocols, as are described herein below, have a different Layer 5header which the processor 92 can utilize in order to separate the audiochannel from the various signaling and control channels. The actualprocessing of these high level protocols is preferably performed by theprocessor 92 with the exception of the voice coding of the audio channeland digital filtering of DTMF tones from the audio channel that arepreferably performed by the DSP card 86.

One of these higher level protocols of Layer 5 (L5) is the Real TimeProtocol (RTP) which when combined with one of the Layer 6 (L6) voicecoding protocols (G.711 that operates at 64 KB/sec, G.729 that operatesat 8 KB/sec and G.723 that operates at either 6.4 or 5.6 KB/sec) canprovide the voice or bearer audio channel. These L5 and L6 protocols runon top of UDP so there is no guarantee of packet delivery, however theservice is fast which is required for real time audio transport. Thebest effort delivery of UDP is appropriate since there is no time forretransmission of data in the event of an error with real time voiceinformation.

Other high level protocols of Layers 5 and 6 include the Real TimeControl Protocol (RTCP) channel which provides supervision of the beareraudio channel; the H.225.0 Registration, Administration, Status (RAS)channel which is used for requesting admission onto a shared networkfrom an “H.323 Gatekeeper” device on the network; and the H.225.0 CallSignaling and H.245 Call Control channels which provide call signalingand control respectively, such as call setup requests, alerting,capabilities exchange and other signaling.

Within preferred embodiments of the present invention, the high levelprotocols of FIG. 5 further include two new protocols, those beingXControl and RemoteUIApp, which together provide a remote screen andsoftkey control channel. In essence, these protocols allow the ACDcontroller 42 to have remote control of, and interaction with, thedisplay screen and softkeys within the remote telephone stations 48.The)(Control protocol is a Layer 5 and 6 (L5, L6) level software thatspecifies the exact format of the display screen messages, softkeyoption label messages and softkey pressed control messages which can beexchanged between the ACD controller 42 and the remote telephonestations 48. The XControl protocol further specifies the headers anddata content of these messages. The RemoteUIApp protocol is anApplication Layer 7 (L7) level software which comprises the differentdisplay screen and softkey option label messages sent from the ACDcontroller 42 and the softkey button pressed control messages sent fromthe remote telephone station 48, assuming the remote telephone station48 is a device utilizing softkeys. In other embodiments in which theremote telephone station 48 is a computing device running an IP softclient program, the RemoteUIApp protocol comprises mouse clicks and/orkeyboard command messages sent from the remote telephone station 48.

The operation of the ACD controller 42 during a call reception operationaccording to preferred embodiments of the present invention is nowdescribed with reference to the flow chart of FIG. 6. This descriptionis specific to the ACD system depicted in FIG. 2 though it could equallyapply to the ACD system of FIG. 3 with some minor modifications as willbe described herein below. It is noted that within the followingdescription of the call reception operation of FIG. 6, only the higherlevel protocols of FIG. 5 are discussed since the processing of thelower level protocols of Layers 1 through 4 for each message being sentbetween the ACD controller 42 and a remote telephone station 48 are asdescribed above with reference to FIG. 5.

Preferably, the steps described for this operation are performed by asoftware algorithm being run on the processor 92 within the ACDcontroller 42. It should be understood though that some or all of thesefunctional steps could alternatively be performed with hard logic and/ordiscrete components. Hence, the steps of FIG. 6 will hereinafter bereferred to as control logic being operated on the ACD controller 42.

Initially within the call reception operation, as depicted at step 120,the ACD controller 42 monitors for a call being initiated with the ACDsystem by a remote telephone station 48. The presence of a callinitiation is confirmed by the ACD controller 42 if call setup messagesare received from a remote telephone station 48, these call setupmessages being contained within the H.225.0 call signaling channel thatis processed by the processor 92. Once the ACD controller 42 detects theinitiation of a call from a remote telephone station 48 with use ofthese call setup messages, the ACD controller 42 proceeds at step 122 toanswer the call by sending other H.225.0 call signaling messages to theremote telephone station 48, these other H.225.0 call signaling messagesbeing consistent with the H.323 VoIP standard.

Next, as depicted at step 124, the ACD controller 42 plays a greetingmessage stored within the hard disk 88 to the user at the remotetelephone station 48 by sending voice data packet(s) containing such avoice message. This greeting preferably includes a welcome salutationthat indicates to the user the corporation corresponding to the ACDsystem. The sending of the voice message to the remote telephone station48 is preferably done by the DMA 96 forwarding a voice file containingthe voice message from the hard disk 88 to the RAM 94 and subsequentlyforwarding the voice file to the DSP card 86. The DSP card 86 thenperforms transcoding on the voice file if it is not in the proper formatfor sending to the remote telephone station 48. Next, the DMA controller96 forwards the voice file to the RAM 94 for lower layer processing bythe processor 92 and eventual outputting to the remote telephone station48.

At this point, the ACD controller 42 proceeds to query the remotetelephone station's capabilities as depicted at step 126. Thecapabilities querying is a standard part of the H.323 protocol and isdone by the H.245 call control protocol. In preferred embodiments of thepresent invention, a vendor specific area within the H.323 protocol isused to further query the capabilities of the remote telephone station48 in terms of the size of the display screen, the number andconfiguration of buttons and softkeys, and whether the remote control ofits display and softkeys is allowed. It is noted that other VoIPprotocols have similar querying capabilities. In alternativeembodiments, querying of the remote telephone station's capabilities isnot performed, as such capabilities could either be indicated within thecall setup messages or be predetermined based upon a universal standard.

It is noted that to continue in the call reception operation of FIG. 6,the capabilities of the remote telephone station 48 must be sufficientto support a minimum functionality and the ACD controller 42 must beallowed to take control of specific operations within the remotetelephone station 48. The minimum functionality includes theinstallation of the new XControl and RemoteUIApp software as describedabove which enables the remote control of the remote telephone station48, as well as some form of user interface. This user interfacepreferably comprises a display screen and softkeys. Further, if a webbrowser operation as is described below with reference to FIG. 9 isallowed, the remote telephone station 48 further must support the HTTPand have a browser application software installed.

As shown at step 128, the ACD controller 42 next sends control signalsto the remote telephone station 48 indicating that the ACD controller 42will control the user interfaces within the particular remote telephonestation 48, the user interfaces preferably being the softkeys anddisplay screen. These control signals are preferably sent via theXControl and RemoteUIApp protocols as described above.

Subsequently, the ACD controller 42 determines whether an attendant isavailable for the user at the remote telephone station 48 at step 130.If an attendant is available, the processor 92 within the ACD controller42 proceeds to perform the XControl and RemoteUIApp software in order tosend a welcome screen message to the remote telephone station 48 that isto be displayed on the display screen at step 132. This welcome screenmessage preferably indicates that the call will be imminently answeredby an attendant and possibly could provide information regarding theattendant, such as a name or identification number, and/or a selectionof services the attendant can provide. Next, the call is forwarded tothe available attendant at step 134. In the case that more than oneattendant is available, the ACD controller 42 preferably performs a loadbalancing operation to ensure that each attendant answers approximatelyan even number of calls and/or is connected with customers for anapproximately even amount of time.

If no attendant is available at step 130, the ACD controller 42 proceedsto determine waiting parameters for the remote telephone station 48 atstep 136. These waiting parameters, according to preferred embodiments,include the number in which the particular remote telephone station 48is within a priority order, the average length of time for a call, andthe estimated wait time before an attendant will answer the call basedupon the multiplication of the number of the call within the priorityorder and the average length of time for a call, divided by the numberof attendants in the ACD system. In some embodiments, these waitingparameters are continuously updated with a rolling average length oftime for a call being calculated. In other embodiments, the waitingparameters are only updated periodically. Next, as depicted at step 138,the ACD controller 42 performs the XControl and RemoteUIApp software inorder to send a waiting screen message and softkey option labels to theremote telephone station 48. The waiting screen message includes thewaiting parameters while the softkey option labels provide a selectionof operations in which the remote telephone station 48 can operate whilewaiting for an attendant. These selection of operations according topreferred embodiments described below, comprise a music choice softkeyoperation in which the user can select a type of music to listen towhile waiting, an alert request softkey operation in which the user canrequest to be alerted when an attendant is available, and a browserrequest softkey operation in which the user can peruse through datainformation with the use of a browser while waiting.

As depicted at step 140, the ACD controller 42 next determines if asoftkey button is pressed by determining if a corresponding softkeypressed control message is received from the remote telephone station48, this softkey pressed control message preferably being sent by theremote telephone station 48 with the XControl and RemoteUIApp softwarebeing run at the remote telephone station 48. If a softkey is notpressed, the ACD controller 42 determines if an attendant is availableat step 142. If an attendant is available at this point, the ACDcontroller 42 proceeds to perform steps 132 and 134 described above forthe establishment of the call with the attendant. If no attendant isavailable, the ACD controller 42 proceeds to determine at step 144 if atimeout period for updating the waiting parameters has expired for theremote telephone station 48. If the timeout period has not expired, theACD controller returns to step 140 within the procedure. If the timeoutperiod has expired, the ACD controller 42 updates the waiting parametersfor the remote telephone station 48 by returning to step 136 within theprocedure. Essentially, steps 140, 142, and 144 can be seen together asmonitoring for one of a softkey button to be pressed, an attendant tobecome available, and a timeout period to expire. In alternativeembodiments, no time out period is measured and instead steps 136 and138 are regularly performed so as to continuously provide the user atthe remote telephone station 48 up-to-date information.

If a softkey button is pressed at step 140, the ACD controller 42proceeds to determine which of the softkey buttons is pressed at step146. This is preferably done simply by reading the softkey pressedcontrol message but alternatively could be performed with use of a queryto the remote telephone station 48 with use of the)(Control andRemoteUIApp software being run on the processor 92. Once the softkeythat is pressed is determined, the ACD controller 42 proceeds to performthe operation corresponding to the label of the softkey pressed, thosebeing the music choice softkey operation at step 148, the alert requestsoftkey operation at step 150 or the browser request softkey operationat step 152. These operations 148,150,152 are now described in detailfor preferred embodiments with reference to FIGS. 7, 8 and 9respectively.

FIG. 7 is a flow chart illustrating the steps performed by the ACDcontroller 42 during the music choice softkey operation 148 according topreferred embodiments. Firstly, the ACD controller 42 sends a musicselection screen message and softkey option labels to the remotetelephone station 160 as depicted at step 160, this screen message andsoftkey option labels being sent by the processor 92 with use of theXControl and RemoteUIApp software. The music selection screen messagepreferably presents a message asking for the user to select a particulartype of music. The softkey option labels that are sent, in this case,provide a selection of music that is available such as “ROCK”,“COUNTRY”, and “LOUNGE”.

Next, as depicted at steps 162 and 164, a softkey being pressed and theavailability of an attendant respectively are monitored for. If anattendant is available at step 164, the ACD controller 42 proceeds toperform steps 132 and 134 described previously for the connection of theremote telephone station 48 to an attendant. If a softkey button isfound to be pressed at step 162 by receiving a softkey pressed controlmessage from the remote telephone station 48 running the XControl andRemoteUIApp software, the ACD controller 42 retrieves a music file fromthe hard disk 88 at step 166 that corresponds to the music type selectedand applies the music file to the bearer channel between the ACDcontroller 42 and the remote telephone station 48 as depicted at step168. The sending of a music file to the remote telephone station 48 ispreferably done in the same manner as described above for the sending ofthe greeting message at step 124. In particular, the sending of themusic file to the remote telephone station 48 is preferably done by theDMA 96 forwarding the music file from the hard disk 88 to the RAM 94 andsubsequently forwarding the music file to the DSP card 86. The DSP card86 then performs transcoding on the music file if it is not in theproper format for sending to the remote telephone station 48. Next, theDMA controller 96 forwards the music file to the RAM 94 for lower layerprocessing by the processor 92 and eventual application to the bearerchannel and outputting to the remote telephone station 48.

Next, the ACD controller 42 returns to the monitoring for an attendantat step 130. Preferably, the ACD controller 42 continues to applyadditional music files to the bearer channel until an attendant isavailable. In alternative embodiments, the user can select one of musictypes, specific music artists or songs, radio stations, and/or otheraudio entertainment selections such as news broadcasts and weatherupdates to be applied to the bearer channel.

FIG. 8 is a flow chart illustrating the steps performed by the ACDcontroller 42 during the alert request softkey operation 150 accordingto preferred embodiments of the present invention. Initially in thisoperation, the processor 92 within the ACD controller 42 sends an alertmode message to the remote telephone station 48 at step 180 with use ofthe XControl and RemoteUIApp software. This alert mode message indicatesto the user that the remote telephone station 48 is now in alert modeand can proceed with normal operations, such as answering/initiatingfurther telephone sessions, until an attendant is available. Inpreferred embodiments, the alert mode message results in the ACDcontroller 42 relinquishing partial control over the user interfaceswithin the remote telephone station 48 at step 180. In the preferredembodiments, the ACD controller 42 still maintains minimal control toprovide updated waiting parameters, as described above, to the remotetelephone station 48 as well as maintaining an alert mode icon on theremote telephone station 48. Next, at step 182, the ACD controller 42sets itself into alert request mode for the particular call by attachingan alert flag to the particular call within the priority order andpreferably ending further communications with the remote telephonestation 48 until an attendant is available with the exception of thesending of waiting parameters as described above. At this point, theuser of the remote telephone station is free to initiate/accept othertelephone sessions.

Subsequently, the ACD controller 42 monitors for an attendant at step184. Once an attendant is available, the ACD controller 42 preferablyreacquires full control of the remote telephone station's userinterfaces and sends at step 186 an alert on message to the remotetelephone station 48. This alert on message, that is sent by theprocessor 92 with use of the XControl and RemoteUIApp software,preferably results in the ringing of the remote telephone station 48with a unique ring tone and the displaying of an alert message on thedisplay screen of the remote telephone station 48. Preferably, theringing of the remote telephone station includes an automatic increasein volume for the ring tone to a maximum level, if not already set tosuch a level. Alternatively, the alert on message could be a standardring or even another type of alerting technique such as the sending ofan email or page to the user.

Next, the ACD controller 42 monitors for an indication that the user hasanswered the alert on message at step 188. This answering of the alerton message is preferably done by the user picking up the receivercorresponding to the remote telephone station 48, though in alternativeembodiments this could be done in a different manner such as pressing asoftkey. If the user does not answer the alert on message, the ACDcontroller 42 determines if an answer timeout period has expired at step190, the expiration of the answer timeout period resulting in thetermination of the telephone call between the ACD controller 42 and theremote telephone station 48. If the answer timeout period is notexpired, the ACD controller 42 continues to monitor for an answer to thealert on message at step 188.

If the user answers the alert on message at step 188, the ACD controller42 proceeds with the connection of the telephone call with the attendantas previously described at steps 132 and 134.

It is noted that, when operating within an alert mode of operation, theremote telephone station 48, according to preferred embodiments of thepresent invention, is a wireless telephone station such as the remotetelephone station of FIG. 2 which communicates with the IP network 40via the base station 52. This embodiment allows for the most flexibilityfor the user since he/she can continue to do other things while waitingfor the attendant to answer his/her call as long as the user carries thewireless telephone. In this embodiment, data messages are sent betweenthe wireless telephone station 48 and the base station 52 along existingdata communication channels in order to enable the operations describedherein for the preferred embodiments.

FIG. 9 is a flow chart illustrating the steps performed by the ACDcontroller 42 during the browser request softkey operation 152 accordingto preferred embodiments of the present invention. First within thisprocedure, the ACD controller 42 sets itself into browser mode at step200, the browser mode including initiating web server software withinthe processor 92. Alternatively, the browser mode could entail theestablishment of an Internet and/or Intranet connection with an externalweb server.

Next, at step 202, the ACD controller 42 proceeds to run an HTTP sessionwith browser software running in the remote telephone station 48including sending specific web page information stored in the hard disk88 of the ACD controller 42 to the remote telephone station 48. In thisimplementation, the processor 92 acts as the web server for the remotetelephone station 48, sending and accepting data to/from the remotetelephone station 48. This HTTP session could allow the user to browsethrough data information related to the corporation corresponding to theACD system. In some embodiments the browser session entails browsingthrough a corporation's web page and/or the Internet.

While the browser session is taking place, the ACD controller 42continues to monitor for an available attendant at step 204. Once anattendant is available, the ACD controller 42 sends an audible alertsignal to the remote telephone station 48 which triggers an audiblealert that the call is being forwarded to an attendant. Next, the ACDcontroller 42 proceeds to connect the remote telephone station 42 to theattendant with use of steps 132 and 134 as described previously. Onceconnected with the remote telephone station 48, the ACD controller 42preferably sends the browser information the user was last viewing tothe console 46 corresponding to the attendant in which the call wasforwarded to. This forwarding of the browser information preferablybeing done by the processor 92 establishing an identical browser sessionwith the console 46 corresponding to the appropriate attendant andrelaying any user input to the attendant. In this manner, both theattendant and the user of the remote telephone station 48 can share andmanipulate the same browser information.

The above description is specific to preferred embodiments of thepresent invention. It is recognized that alternative embodiments arepossible while staying within the scope of the present invention. Inparticular, not all of the steps of FIGS. 6, 7, 8 and 9 are requiredwithin embodiments of the present invention. For instance, somealternative embodiments enable only one or two of the music requestsoftkey operation 148, the alert request softkey operation 150 and thebrowser request softkey operation 152. In fact, in some alternativeembodiments, none of these operations 148,150,152 are enabled and theACD controller 42 only provides waiting parameter information to theuser. Further alternatives, do not use softkeys as a user interface butrather use other techniques for the user to select between a number ofoptions such as hard wired keys, DTMF keys, voice recognition software,mouse clicks and/or keyboard commands. In the case of DTMF keys or voicerecognition software, it should be understood that the DSP card 86 canperform voice codec algorithms to retrieve the unencoded voice and/orperform digital filtering on the audio channel in order to retrieve theDTMF information. In the case of voice recognition being used, a furthervoice recognition software must be run within the ACD controller 42,preferably on the processor 92.

As mentioned previously, the ACD controller 42 could equally beimplemented within the ACD system of FIG. 3 which includes an ACD LAN56. The key difference required in this alternative is simply that allcommunications between the ACD controller 42 and the remote telephonestations 48 and communications between the attendant telephone stations44 and the remote telephone stations 48 must traverse the interfacebetween the ACD LAN 56 and the IP network 40. As described previously,this interface in preferred embodiments is a router or firewall device.

Yet further alternative embodiments provide a different structure to theoverall call reception operation of FIG. 6. In one such alternativeembodiment, a user calling the ACD system is initially entered into anoperation similar to the browser request softkey operation 152 no matterif an attendant is available or not. This could possibly allow the userto acquire the information needed without the need of an attendantand/or allow the attendant to monitor the user's selections while in thebrowser session to determine a strategy for dealing with the particularuser. In this alternative embodiment, the user of the remote telephonestation 48 might only be connected to an attendant if he/she sends anattendant request message to the ACD controller 42.

In even further embodiments of the present invention, the ACD controller42 could further be used to provide a variety of other options such asstock quotes, advertising, games, etc. while the user is waiting for anattendant.

All of the embodiments of the present invention described above areimplemented with use of a packet-based network, that preferably beingthe IP network 40. In a further embodiment of the present invention, astandard analog network is utilized similar to that illustrated withinFIG. 1. In this embodiment, an alert request operation is capable ofbeing implemented within a switch device (not shown) within the analogtelephone network 20 or alternatively within the ACD controller 22 oryet alternatively within the remote telephone station 24 itself. FIG. 10is a flow chart illustrating the steps performed by the switch deviceaccording to this embodiment during an alert request operation. Itshould be understood that similar steps to those described below wouldbe required if the alert request operation was implemented within theACD controller 22. Modifications required if the alert request operationof FIG. 10 was implemented within the remote telephone station 24 isdescribed after the description of FIG. 10.

Firstly, a telephone session is initiated with the ACD controller 22 byone of the remote telephone stations 24. If the user is notified thathe/she will have to wait to be connected with an attendant, the usercould, at this point, press a specific DTMF code that indicates to theswitch device to perform the alert request operation. Preferably, theDTMF code is a “*” key followed by a predetermined digital code. Asdepicted in FIG. 10, the first step in the operation within the switchdevice is to monitor for the enabling of the alert request operation atstep 220. Next, the switch device determines and stores the telephonedirectory number corresponding to the remote telephone station 24 atstep 222 and disables the connection between the remote telephonestation 24 and the ACD controller 22 at step 224, the connectionremaining between the ACD controller 22 and the switch device. At thispoint, the user of the remote telephone station 24 can answer/initiateother telephone sessions that would not have been possible if stillconnected to the ACD system.

Subsequently, the switch device operates to play a recorded instructionmessage to the ACD controller 22 at step 226. This instruction messagein one preferable embodiment states “Please press the pound key when anattendant is available”. In this case, if the call is transferred to anattendant, the attendant will hear this recording and will presumablypress the “#” key when ready to answer the call, the pressing of the “#”key generally being referred to as an attendant available indication. Asdepicted at step 228, the switch device will operate to monitor for anattendant available indication at step 228. If no such indication isdetected, the switch device returns to step 226 and replays the recordedinstruction message. Once the switch device detects an attendantavailable indication at step 228, the switch device proceeds to initiatea telephone session with the remote telephone station 24 at step 230.This initiation preferably includes sending a ring tone that is uniquefor this particular operation so that the user understands that anattendant is available. Once the user has answered the ring tone, theswitch device connects the call as if the remote telephone station 24was connected to the ACD controller 22 the entire waiting period.

In an alternative embodiment, rather than performing steps 226 and 228,the switch device monitors for a ring back which is typically generatedwhen a telephone session is transferred. In this case, a ring backindicates that the call is being transferred to an attendant. Therefore,when a ring back is detected, the switch device proceeds with step 230described previously.

In the case that the alert request operation of FIG. 10 is performed bythe remote telephone station 24 itself, there are a couple of keymodifications. Essentially, the algorithm of FIG. 10 is identical butwith steps 222 and 224 removed and step 230 only including the ringingof the telephone station 24 and not the re-initiation of the telephonesession. In this case, the connection is maintained between the remotetelephone station 24 and the ACD controller 22, and so the telephonestation 24 cannot initiate/accept other telephone sessions while waitingfor the attendant. There is still the advantage of not having to waitimmediately next to the remote telephone station 24 in this case due tothe telephone station 24 ringing when the attendant is available.

There are a large number of advantages to the embodiments of the presentinvention as described herein above. One key advantage of theseembodiments is with respect to the incredible amount of flexibilitygiven to a person calling a ACD system. The person calling the ACDsystem preferably is provided an estimated waiting time, a selection ofmusic, a possible alert indication when an attendant is available andthe ability to browse for information while waiting. These capabilitieswill decrease the frustrations felt by people attempting to contact anattendant by making the waiting period more pleasant.

Persons skilled in the art will appreciate that there are yet morealternative implementations and modifications possible for implementingthe present invention, and that the above implementations are onlyillustrations of certain embodiments of the invention. The scope of theinvention, therefore, is only to be limited by the claims appendedhereto.

1.-35. (canceled)
 36. A method of operating a telecommunicationsterminal, the method comprising: receiving an attendant-ready indicationfrom a remote system; initiating a voice call in response to receipt ofthe attendant-ready indication; and alerting a user of thetelecommunications terminal to the call initiation.
 37. A method asdefined in claim 36 wherein alerting the user of the telecommunicationsterminal to the call initiation comprises audibly alerting the user ofthe telecommunications terminal to the call initiation.
 38. A method asdefined in claim 37, wherein audibly alerting the user of thetelecommunications terminal to the call initiation comprises audiblyalerting the user of the telecommunications terminal with a first ringtone which is distinct from a ring tone used to alert the user of thetelecommunications terminal to an incoming call.
 39. A method as definedin claim 36, wherein alerting the user of the telecommunicationsterminal to the call initiation comprises sending a page to the user.40. A method as defined in claim 36, wherein alerting the user of thetelecommunications terminal to the call initiation comprises sending anemail to the user.
 41. A method as defined in claim 36, whereininitiating the voice call comprises initiating a voice call to anAutomatic Call Distribution (ACD) system.
 42. A method as defined inclaim 41, wherein the remote system is the ACD system.
 43. A method asdefined in claim 36, further comprising sending an alert request messageto the remote system before receiving the attendant-ready indication.44. A method as defined in claim 43, wherein sending the alert requestmessage comprises sending at least one predetermined DTMF tone to theremote system.
 45. A method as defined in claim 43, further comprisingreceiving waiting parameters for display at the terminal from the remotesystem after sending the alert request message.
 46. A method as definedin claim 45, wherein the waiting parameters comprise at least one of anestimated waiting time, a position of the user in a queue and an averagelength of time for a call.
 47. A method as defined in claim 44, furthercomprising displaying a call alert mode icon at the terminal betweensending the alert request message and receiving the attendant-readyindication.
 48. A method as defined in claim 43, further comprisingmaintaining a connection to the remote system between sending the alertrequest message and receiving the attendant-ready indication.
 49. Amethod as defined in claim 43, further comprising sending information tothe remote system indicating how to send an attendant-ready indicationto the telecommunications terminal.
 50. A method as defined in claim 49,wherein the information sent to the remote system indicating how to sendan attendant-ready indication is a recorded voice message.
 51. A methodas defined in claim 50, wherein sending information to the remote systemindicating how to send an attendant-ready indication is sentperiodically until an attendant-ready indication is received.
 52. Atelecommunications terminal, comprising: a receiver operable to receivean attendant-ready indication from a remote system; call control logicoperable to initiate a voice call in response to receipt of theattendant-ready indication; and an alerter operable to alert a user ofthe telecommunications terminal to initiation of the voice call.
 53. Aterminal as defined in claim 52 wherein the alerter is operable toaudibly alert the user of the telecommunications terminal.
 54. Aterminal as defined in claim 53, wherein the alerter is operable toaudibly alert the user of the telecommunications terminal with a firstring tone which is distinct from a ring tone used to alert the user ofthe telecommunications terminal to an incoming call.
 55. A terminal asdefined in claim 52, wherein the alerter is operable to alert the userof the telecommunications terminal by sending a page to the user.
 56. Aterminal as defined in claim 52, wherein the alerter is operable toalert the user of the telecommunications terminal by sending an email tothe user.
 57. A terminal as defined in claim 52, wherein the callcontrol logic is operable to initiate a voice call to an Automatic CallDistribution (ACD) system.
 58. A terminal as defined in claim 57,wherein the receiver is operable to receive the attendant-readyindication from the ACD system.
 59. A terminal as defined in claim 52,further comprising a transmitter operable to send an alert requestmessage to the remote system before receiving the attendant-readyindication.
 60. A terminal as defined in claim 59, wherein thetransmitter is operable to send the alert request message by sending atleast one predetermined DTMF tone to the remote system.
 61. A terminalas defined in claim 60, wherein the receiver is operable to receivewaiting parameters for display at the telecommunications terminal fromthe remote system after sending the alert request message.
 62. Aterminal as defined in claim 61, wherein the waiting parameters compriseat least one of an estimated waiting time, a position of the user in aqueue and an average length of time for a call.
 63. A terminal asdefined in claim 59, further comprising a display operable to display acall alert mode icon when the telecommunications terminal is in a callalert mode.
 64. A terminal as defined in claim 60, wherein the callcontrol logic is operable to maintain a connection to the remote systembetween sending the alert request message and receiving theattendant-ready indication.
 65. A terminal as defined in claim 60,wherein the transmitter is operable to send information to the remotesystem indicating how to send an attendant-ready indication to thetelecommunications terminal.
 66. A terminal as defined in claim 65,wherein the transmitter is operable to send a recorded voice message tothe remote system indicating how to send an attendant-ready indication.67. A terminal as defined in claim 66, wherein the transmitter isoperable to send the information to the remote system indicating how tosend an attendant-ready indication periodically until an attendant-readyindication is received.